Tap card to securely generate card data to copy to clipboard

ABSTRACT

A processor of a computing device may receive, from a contactless card, a uniform resource locator (URL) and a cryptogram. An operating system (OS) executing on the processor may open an application based on the URL. The application may transmit the cryptogram to an authentication server. The application may receive, based on the server verifying the cryptogram, an account number. The application may store the account number in a memory of the device.

RELATED APPLICATIONS

This application is a continuation application of U.S. Ser. No.17/684,780, filed Mar. 2, 2022, which is a continuation application ofU.S. patent application Ser. No. 17/382,541, filed on Jul. 22, 2021,which is a continuation of U.S. patent application Ser. No. 16/265,937,titled “TAP CARD TO SECURELY GENERATE CARD DATA TO COPY TO CLIPBOARD”filed on Feb. 1, 2019. The contents of the aforementioned applicationare incorporated herein by reference in their entirety.

TECHNICAL FIELD

Embodiments herein generally relate to computing platforms, and morespecifically, to tapping a card to a computing device to securelygenerate card data which can be copied to a clipboard of the computingdevice.

BACKGROUND

Account identifiers for payment cards are often long numeric and/orcharacter strings. As such, it is difficult for a user to manually enterthe account identifier correctly. Indeed, users often make mistakes andenter incorrect account identifiers into computing interfaces (e.g.,payment interfaces). Furthermore, processes have been developed thatallow cameras to capture and identify account identifiers entered in adevice, thereby posing security risks to account identifiers. Furtherstill, certain operating systems restrict the ability to accessidentifiers stored on a contactless card, which blocks conventionalattempts to programmatically copy and/or paste the account identifier.

SUMMARY

Embodiments disclosed herein provide systems, methods, articles ofmanufacture, and computer-readable media for tapping a contactless cardto securely generate card data to copy to a clipboard. According to oneexample, a web browser executing on a processor circuit may output aform comprising a payment field. A uniform resource locator (URL) may bereceived from a communications interface of a contactless card, the URLcomprising encrypted data generated by the contactless card based atleast in part on a private key for the contactless card stored in amemory of the contactless card. An application executing on theprocessor circuit may transmit the encrypted data to an authenticationserver, the authentication server to verify the encrypted data bydecrypting the encrypted data based at least in part on a private keyfor the contactless card stored in a memory of the authenticationserver. The application may receive, from a virtual account numberserver based on the verification of the encrypted data by theauthentication server, a virtual account number. The application mayreceive an expiration date associated with the virtual account number,and a card verification value (CVV) associated with the virtual accountnumber. The application may copy the virtual account number to aclipboard of an operating system (OS) executing on the processorcircuit. The OS may paste the virtual account number from the clipboardto the payment field of the form in the web browser. The OS may output anotification comprising the expiration date and the CVV associated withthe virtual account number.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A-1C illustrate embodiments of a system to tap a contactless cardto securely generate card data to copy to a clipboard.

FIGS. 2A-2D illustrate embodiments of tapping a contactless card tosecurely generate card data to copy to a clipboard.

FIGS. 3A-3D illustrate embodiments of tapping a contactless card tosecurely generate card data to copy to a clipboard.

FIG. 4 illustrates an embodiment of a first logic flow.

FIG. 5 illustrates an embodiment of a second logic flow.

FIG. 6 illustrates an embodiment of a third logic flow.

FIG. 7 illustrates an embodiment of a computing architecture.

DETAILED DESCRIPTION

Embodiments disclosed herein provide secure techniques to use acontactless card to generate card data (e.g., an account number,expiration date, customer billing address, shipping address, and/or cardverification value (CVV)) which can be copied to a clipboard of acomputing device. Generally, the contactless card may come withincommunications range of a computing device, e.g., via a tap gesture.Doing so causes the contactless card to generate a uniform resourcelocator (URL), which is transmitted to the computing device. The URL mayinclude data used by an authentication server as part of a validationprocess. For example, the URL may include encrypted data that isdecrypted by the server as part of the validation process. As anotherexample, the URL may include a unique identifier associated with thecontactless card, which is used by the authentication server as part ofthe validation process. Once validated, the authentication server mayinstruct a virtual account number server to generate card data for theaccount associated with the contactless card. The card data may includea virtual account number, an expiration date, and a CVV. The generatedcard data may then be transmitted to the computing device. In someembodiments, account holder information (e.g., name, billing address,shopping address, etc.) may also be transmitted to the computing device.The computing device may copy at least one element (e.g., the virtualaccount number, expiration date, and/or CVV) of the card data and/or theaccount holder information (e.g., the name, billing address, and/orshopping address) to the clipboard. Once copied to the clipboard, thedata may be copied into a corresponding field of a form in a web browserand/or other application. Furthermore, a notification may be outputtedwhich includes the one or more elements of the generated card dataand/or the account holder information. The notification may allow otherelements of data to be copied to the clipboard, which may then be pastedto the payment fields of the form.

Advantageously, embodiments disclosed herein improve security of alldevices and associated data. For example, some operating systems mayrestrict access to data stored in contactless cards, and/or specifictypes of data stored in contactless cards. Therefore, conventionaltechniques to copy and/or autofill card data cannot function properly.Advantageously, however, embodiments disclosed herein allow card data tobe securely generated, transmitted, copied, and/or autofilled in anytype of operating system. Furthermore, conventional approaches requirethe user to manually enter card data into a form. However, doing so mayallow other users or devices to capture the card data as the user entersthe card data into the form. By eliminating the need for the user tomanually enter card data into the form, the security of the card data isenhanced. Furthermore, the validation performed by the server providesan additional safeguard to ensure that the correct card data is beingentered into the form. Additionally, the generation and filling ofvirtual card numbers into the form protects the security of the actualaccount number of the contactless card, as conventional solutionsrequire providing the actual account number of the contactless card intothe form.

With general reference to notations and nomenclature used herein, one ormore portions of the detailed description which follows may be presentedin terms of program procedures executed on a computer or network ofcomputers. These procedural descriptions and representations are used bythose skilled in the art to most effectively convey the substances oftheir work to others skilled in the art. A procedure is here, andgenerally, conceived to be a self-consistent sequence of operationsleading to a desired result. These operations are those requiringphysical manipulations of physical quantities. Usually, though notnecessarily, these quantities take the form of electrical, magnetic, oroptical signals capable of being stored, transferred, combined,compared, and otherwise manipulated. It proves convenient at times,principally for reasons of common usage, to refer to these signals asbits, values, elements, symbols, characters, terms, numbers, or thelike. It should be noted, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to those quantities.

Further, these manipulations are often referred to in terms, such asadding or comparing, which are commonly associated with mentaloperations performed by a human operator. However, no such capability ofa human operator is necessary, or desirable in most cases, in any of theoperations described herein that form part of one or more embodiments.Rather, these operations are machine operations. Useful machines forperforming operations of various embodiments include digital computersas selectively activated or configured by a computer program storedwithin that is written in accordance with the teachings herein, and/orinclude apparatus specially constructed for the required purpose or adigital computer. Various embodiments also relate to apparatus orsystems for performing these operations. These apparatuses may bespecially constructed for the required purpose. The required structurefor a variety of these machines will be apparent from the descriptiongiven.

Reference is now made to the drawings, wherein like reference numeralsare used to refer to like elements throughout. In the followingdescription, for the purpose of explanation, numerous specific detailsare set forth in order to provide a thorough understanding thereof. Itmay be evident, however, that the novel embodiments can be practicedwithout these specific details. In other instances, well knownstructures and devices are shown in block diagram form in order tofacilitate a description thereof. The intention is to cover allmodification, equivalents, and alternatives within the scope of theclaims.

FIG. 1A depicts a schematic of an exemplary system 100, consistent withdisclosed embodiments. As shown, the system 100 includes one or morecontactless cards 101, one or more mobile devices 110, an authenticationserver 120, and a virtual account number server 140. The contactlesscards 101 are representative of any type of payment card, such as acredit card, debit card, ATM card, gift card, and the like. Thecontactless cards 101 may comprise one or more communications interfaces150, such as a radio frequency identification (RFID) chip, configured tocommunicate with the mobile devices 110 via NFC, the EMV standard, orother short-range protocols in wireless communication. Although NFC isused as an example communications protocol, the disclosure is equallyapplicable to other types of wireless communications, such as the EMVstandard, Bluetooth, and/or Wi-Fi. The mobile devices 110 arerepresentative of any type of network-enabled computing devices, such assmartphones, tablet computers, wearable devices, laptops, portablegaming devices, and the like. The servers 120, 140 are representative ofany type of computing device, such as a server, workstation, computecluster, cloud computing platform, virtualized computing system, and thelike.

As shown, a memory 111 of the mobile device 110 includes an instance ofan operating system (OS) 112. Example operating systems 112 include theAndroid® OS, iOS®, Linux®, and Windows® operating systems. As shown, theOS 112 includes an account application 113, a clipboard 114, and a webbrowser 115. The account application 113 allows users to perform variousaccount-related operations, such as viewing account balances, purchasingitems, and/or processing payments. In some embodiments, a user mustauthenticate using authentication credentials to access the accountapplication 113. For example, the authentication credentials may includea username and password, biometric credentials, and the like. In someembodiments, the authentication server 120 may provide the requiredauthentication as described in greater detail below. The web browser 115is an application that allows the mobile device 110 to accessinformation via the network 130 (e.g., via the Internet). For example, auser may make purchases from a merchant's website using the web browser115. The web browser 115 is one example of an application used to accessinformation via the network 130 (e.g., to make purchases). The use of aweb browser as a reference example herein should not be consideredlimiting of the disclosure, as the disclosure is equally applicable toother types of applications used to access information via the network,such as applications provided by merchants that allow users to makepurchases.

When using the web browser 115 (or another application), a user mayencounter a form that includes one or more payment fields.Conventionally, the user is required to manually enter their cardnumber, expiration date, and/or CVV. Some mobile operating systems allowsuch data to be autofilled into forms, but other mobile operatingsystems impose restrictions on autofilling such data. Advantageously,embodiments disclosed herein solve such issues by leveraging thecontactless card 101 to trigger the generation of a virtual accountnumber, expiration date, and/or CVV that can be copied to the clipboard114 of the OS 112.

More specifically, a user may tap the contactless card 101 to the mobiledevice 110, thereby bringing the contactless card 101 sufficiently closeto the card reader 118 of the mobile device 110 to enable NFC datatransfer between the communications interface 150 of the contactlesscard 101 and the card reader 118 of the mobile device 110. In someembodiments, the mobile device 110 may trigger the card reader 118 viaan application program interface (API) call. In one example, the mobiledevice 110 triggers the card reader via an API call responsive to theuser tapping or otherwise selecting an element of the user interface,such as a form field. In addition and/or alternatively, the mobiledevice 110 may trigger the card reader 118 based on periodically pollingthe card reader 118. More generally, the mobile device 110 may triggerthe card reader 118 to engage in communications using any feasiblemethod. After communication has been established between mobile device110 and contactless card 101, the contactless card 101 generates amessage authentication code (MAC) cryptogram. In some examples, this mayoccur when the contactless card 101 is read by the account application113. In particular, this may occur upon a read, such as an NFC read, ofa near field data exchange (NDEF) tag, which may be created inaccordance with the NFC Data Exchange Format.

More generally, the applet 103 executing on a processor (not pictured)of the contactless card 101 generates and transmits data to the mobiledevice 110 via the communications interface 150. In some embodiments,the data generated by the contactless card 101 may include a URL. TheURL may be directed to the authentication server 120, or some other URLassociated with an entity issuing the contactless card 101. The URL mayfurther be a universal link URL that opens a local resource (e.g., apage of the account application 113). The URL may further include data(e.g., parameters) used by the authentication server 120 to validate thedata generated by the contactless card 101.

For example, the applet 103 of the contactless card 101 may use acryptographic algorithm to generate a cryptographic payload based atleast in part on the private key 104 stored in the memory 102 of thecontactless card 101. Generally, the applet 103 may use any type ofcryptographic algorithm and/or system to generate the cryptographicpayload, and the use of a specific cryptographic algorithm as an exampleherein should not be considered limiting of the disclosure. Thecryptographic algorithm may include encryption algorithms, hash-basedmessage authentication code (HMAC) algorithms, cipher-based messageauthentication code (CMAC) algorithms, and the like. Non-limitingexamples of the cryptographic algorithm may include a symmetricencryption algorithm such as 3DES or AES128; a symmetric HMAC algorithm,such as HMAC-SHA-256; and a symmetric CMAC algorithm such as AES-CMAC.In some embodiments, the applet 103 may perform encryption using a keydiversification technique to generate the cryptographic payload.Examples of key diversification techniques are described in U.S. patentapplication Ser. No. 16/205,119, filed Nov. 29, 2018. The aforementionedpatent application is incorporated by reference herein in its entirety.The applet 103 of the contactless card 101 may include the cryptographicpayload as a parameter of the URL.

As another example, the applet 103 of the contactless card 101 mayinclude, in the URL, some other string used to identify the contactlesscard 101. For example, the URL may include a subset of the digits (orcharacters) of an account number associated with the contactless card101. For example, if the account number is 16 digits, the applet 103 ofthe contactless card 101 may include 4 of the digits of the accountnumber as a parameter of the URL. The account number may be any type ofaccount number, such as a primary account number (PAN), a one-time usevirtual account number, and/or a token generated based on the PAN.

The applet 103 may then transmit the generated data to the mobile device110, which may transmit the received data to the authentication server120. The authentication application 123 may then authenticate thereceived data. For example, if the URL includes the cryptographicpayload, the authentication application 123 may decrypt thecryptographic payload using a copy of the private key 104 stored in thememory 122 of the server 120. The private key 104 may be identical tothe private key 104 stored in the memory 102 of the contactless card101, where each contactless card 101 is manufactured to include a uniqueprivate key 104 (and the server 120 stores a corresponding copy of eachunique private key 104). Therefore, the authentication application 123may successfully decrypt the cryptographic payload, thereby verifyingthe payload. As another example, the authentication application 123 mayconfirm that the digits of the account number match digits of theaccount number associated with the contactless card 101 stored in theaccount data 124, thereby verifying the account number.

Regardless of the verification technique used by the authenticationapplication 123, once verified, the authentication application 123 mayinstruct the virtual account number (VAN) generator 142 in the memory141 of the virtual account number server 140 to generate a virtualaccount number, expiration date, and CVV for the account associated withthe contactless card 101. In at least one embodiment, the virtualaccount number generated by the VAN generator 142 is restricted to aspecific merchant, or group of merchants. The virtual account number mayfurther include other restrictions (e.g., time restrictions, locationrestrictions, amount restrictions, etc.). Once generated, the VANgenerator 142 may provide the virtual account number, expiration date,and CVV to the mobile device 110 and/or the authentication server 120.The VAN generator 142 and/or the authentication server 120 may furtherprovide the account holder name, billing address, and/or shippingaddress to the mobile device 110. In some embodiments, however, theaccount holder name, shipping address, and/or billing address are storedlocally by the mobile device 110. The VAN generator 142 and/or theauthentication server 120 may provide the data to the mobile device 110via any suitable method, such as a push notification, text message,email, via the web browser 115, etc.

Once received by the mobile device 110, the virtual account number, theexpiration date, the CVV, the account holder name, billing address,and/or shipping address may be copied to the clipboard 114 of the OS112. Doing so allows the user to paste the copied data to thecorresponding field in the web browser 115. For example, the user maypaste the account number to an account number field of the form in theweb browser 115. In some embodiments, a notification may be outputted onthe mobile device 110 that includes the expiration date and CVV. Thenotification may further include the account holder name, billingaddress, and/or shipping address. The notification may be outputtedafter some predefined amount of time (e.g., 5 seconds after the virtualaccount number is copied to the clipboard 114). The notification mayallow the user to directly copy the account holder name, billingaddress, shipping address, expiration date and/or CVV to the clipboard114 for pasting into corresponding fields of the form in the web browser115.

Generally, the clipboard 114 stores data that can be copied and/orpasted within the OS 112. For example, the clipboard 114 may store datalocally for pasting into fields of the mobile device 110, and a user mayinput/paste the data stored in the clipboard 114 using a command and/orgesture available within the OS 112. For example, copying the accountnumber to the clipboard 114 allows the user to paste the account numberto the corresponding form field using a command and/or gesture availablewithin the OS 112. Further still, the account application 113 may outputa notification which specifies the expiration date and the CVV while theaccount number is copied to the clipboard 114. Doing so allows the userto manually enter the expiration date and CVV to the corresponding formfields while the notification remains in view. In some embodiments, theaccount application 113 and/or the OS 112 may also copy the expirationdate, billing address, and/or the CVV to the clipboard 114, allowing theexpiration date, billing address, and/or the CVV to be pasted to thecorresponding form fields.

FIG. 1B depicts an embodiment where the applet 103 of the contactlesscard 101 generates a cryptographic payload for verification by theauthentication application 123. As stated, when a user may encounter apayment form in the web browser 115. In response, the OS 112 and/or theaccount application 113 may output a notification instructing the userto tap the contactless card 101 to the mobile device 110. In someembodiments, the user may select a form field associated with payment(e.g., an account number field, expiration date field, and/or CVVfield), which brings focus to the form field. In such embodiments, theOS 112 and/or the account application 113 may output the notification totap the contactless card 101 to the mobile device 110 upon determiningthe payment field has received focus. As another example, the OS 112and/or the account application 113 may determine that the form includesone or more payment fields. For example, in some embodiments, theaccount application 113 and/or OS 112 reads metadata of a form field todetermine the type of information. For example, the metadata of a formfield may specify that the form field is associated with the accountnumber field, expiration date field, CVV field, shipping address field,and/or billing address field. In some embodiments, information such asthe 16-digit card number, CVV, and customer name may be availableoffline, while other information such as addresses and generated virtualnumbers are not available offline and may require a network connection.In response, the account application 113 and/or the OS 112 may output anotification to tap the contactless card 101 to the mobile device 110.Therefore, the account application 113 and/or the OS 112 may output thenotification to tap the contactless card 101 to the mobile device 110based on automatically determining that the form includes one or morepayment fields and/or based on determining that the payment field hasreceived focus.

Once tapped, the applet 103 of the contactless card 101 may generateencrypted data 105 based on the private key 104. In one embodiment, oncethe contactless card 101 is tapped to the mobile device 110, thecontactless card 101 generates and transmits the encrypted data 105 tothe mobile device 110. In another embodiment, once the contactless card101 is tapped to the mobile device 110, the account application 113 mayinstruct the contactless card 101 to generate and transmit the encrypteddata 105 to the mobile device 110. In some embodiments, the encrypteddata 105 may be a string of characters, for example, “A1B2C3Z”. Theapplet 103 may further determine a URL 106. The URL 106 may be directedto the authentication server 120. In some embodiments, the applet 103dynamically generates the URL 106. In other embodiments, the applet 103dynamically selects a URL 106 that is one of a plurality of URLs 106stored in the memory 102. In some embodiments, the URL 106 is auniversal link that opens one or more pages of the account application113. The applet 103 may include the generated encrypted data 105 as aparameter of the URL 106, thereby generating a URL with encrypted data108. For example, the URL 106 may be “http://www.example.com/”.Therefore, the URL with encrypted data 108 may be“http://www.example.com/?A1B2C3Z”.

In some embodiments, the applet 103 may encode the encrypted data 105according to an encoding format compatible with URLs prior to includingthe encrypted data 105 as a parameter of the URL 106. For example, theencrypted data 105 may be a string of binary data (e.g., zeroes andones), which may not be compatible with URLs. Therefore, the applet 103may encode the encrypted data 105 to the American Standard Code forInformation Interchange (ASCII) base64 encoding format. Doing sorepresents the binary encrypted data 105 in an ASCII string format bytranslating it into a radix-64 representation (e.g., “ABC123Z” in theprevious example).

The contactless card 101 may then transmit the URL with encrypted data108 to the mobile device 110. The account application 113 may then beopened to the corresponding page, where the account application 113extracts the encrypted data 105 from the URL with encrypted data 108. Insome embodiments, if the user is not logged in to the accountapplication 113, the account application 113 opens a login page wherethe user provides credentials to log in to an account in prior toextracting the encrypted data 105. The account application 113 may thentransmit the encrypted data 105 to the authentication server 120 via thenetwork 130. In one embodiment, the account application 113 transmitsthe encrypted data to the URL 106 generated by the contactless card 101.In other embodiments, as described in greater detail below, the URL withencrypted data 108 causes the web browser 115 to open a new tab andfollow the URL with encrypted data 108. In such embodiments, the URLwith encrypted data 108 leads to the authentication application 123,which may extract the encrypted data 105 from the URL with encrypteddata 108.

Once received, authentication application 123 may then attempt todecrypt the encrypted data 105 using the private key 104 associated withthe contactless card 101. As stated, in some embodiments, the encrypteddata 105 is encoded by the applet 103. In such embodiments, theauthentication application 123 may decode the encrypted data 105 priorto the attempted decryption. If the authentication application 123 isunable to decrypt the encrypted data to yield an expected result (e.g.,a customer identifier of the account associated with the contactlesscard 101, etc.), the authentication application does not validate theencrypted data 105, and does not instruct the VAN generator 142 togenerate a virtual account number. If the authentication application 123is able to decrypt the encrypted data to yield an expected result (e.g.,the customer identifier of the account associated with the contactlesscard 101, etc.), the authentication application validates the encrypteddata 105, and instructs the VAN generator 142 to generate a virtualaccount number, expiration date, and CVV value. As shown, the VANgenerator 142 generates a virtual number 125 comprising the virtualaccount number, expiration date, and CVV value.

The virtual number 125 may then be transmitted to the mobile device 110via the network. Once received, the account application 113 provides oneor more elements of the virtual number 125 to the clipboard 114 of theOS 112. For example, the account application 113 may extract the virtualaccount number from the virtual number 125 and provide the extractedvirtual account number to the clipboard 114, thereby copying the virtualaccount number to the clipboard 114. Doing so allows the user to returnto the web browser 115 and paste the virtual account number from theclipboard to the account number field of the form in the web browser115.

FIG. 1C depicts an embodiment where the applet 103 of the contactlesscard 101 generates an identifier for verification by the authenticationapplication 123. As stated, when a user may encounter a payment form inthe web browser 115. In response, the OS 112 and/or the accountapplication 113 may output a notification instructing the user to tapthe contactless card 101 to the mobile device 110. In some embodiments,the user may select a form field associated with payment (e.g., anaccount number field, expiration date field, and/or CVV field), whichbrings focus to the form field. In such embodiments, the OS 112 and/orthe account application 113 may output the notification to tap thecontactless card 101 to the mobile device 110 upon determining thepayment field has received focus.

Responsive to the tap, the applet 103 of the contactless card determinesan identifier to include as a parameter of the URL 106. In oneembodiment, the applet 103 selects a predefined number of characters ofthe account identifier 107 associated with the contactless card 101. Forexample, the applet 103 may select the last 4 digits of the account ID107, and append the selected digits to the URL 106, thereby generatingthe URL with account ID 109. As stated, the URL 106 may be a universallink that opens one or more predefined pages of the account application113.

The contactless card 101 may then transmit the URL with account ID 109to the mobile device 110. The account application 113 may then be openedto the corresponding page, where the account application 113 extractsthe digits of the account ID 107 from the URL with account ID 109. Insome embodiments, if the user is not logged in to the accountapplication 113, the account application 113 opens a login page wherethe user provides credentials to log in to an account in prior toextracting the encrypted data 105. The account application 113 may thentransmit the digits of the account ID 107 to the authentication server120 via the network 130. The authentication application 123 may thenvalidate the account ID 107. For example, the authentication application123 may determine whether the digits of the account ID 107 match thecorresponding digits of the account identifier for the accountassociated with the contactless card 101 in the account data 124. Insuch embodiments, the account application 113 may provide data (e.g., anaccount token, a username associated with the account currently loggedin to the account application 113, etc.) allowing the authenticationapplication 123 to verify that the account ID 107 is associated with anaccount in the account data 124.

If the authentication application 123 verifies the account ID 107, theauthentication application 123 instructs the VAN generator 142 togenerate a virtual account number. Otherwise, a virtual account numberis not generated responsive to the tap of the contactless card 101. Inone embodiment, if the authentication application 123 is able to verifythe account, the authentication application 123 may cause the accountapplication 113 to log in to the corresponding account without requiringuser input.

As shown, after verification of the account ID 107 by the authenticationapplication 123, the VAN generator 142 generates a virtual number 126comprising a virtual account number, expiration date, and CVV value. Thevirtual number 126 may then be transmitted to the mobile device 110 viathe network. Once received, the account application 113 provides one ormore elements of the virtual number 126 to the clipboard 114 of the OS112. For example, the account application 113 may extract the virtualaccount number from the virtual number 126 and provide the extractedvirtual account number to the clipboard 114, thereby copying the virtualaccount number to the clipboard 114. Doing so allows the user to returnto the web browser 115 and paste the virtual account number from theclipboard to the account number field of the form in the web browser115. The expiration date and/or CVV may similarly be extracted by theaccount application 113 and provided to the clipboard 114. Doing soallows the expiration date and/or CVV may be pasted from the clipboard114 into the corresponding fields in the form of the web browser 115.

As stated, the VAN generator 142 and/or the authentication server 120may further provide the account holder name, billing address, and/orshipping address to the mobile device 110. In some embodiments, however,the account holder name, shipping address, and/or billing address arestored locally by the account application 113 and/or the mobile device110. Therefore, in such embodiments, the account application 113 mayprovide the account holder name, billing address, and/or shippingaddress to the clipboard 114. Doing so allows the user to paste theaccount holder name, shipping address, and/or billing address from theclipboard to the account number field of the form in the web browser115.

FIG. 2A is a schematic 200 depicting an example embodiment of tappingthe contactless card 101 to generate a virtual account number and copythe virtual account number to the clipboard 114. As shown, the webbrowser 115 outputs a form including form fields 201-203 (e.g. a paymentform), where field 201 corresponds to an account number field, field 202corresponds to an expiration date field, and field 203 corresponds to aCVV field. As shown, a notification 204 is outputted by the OS 112and/or the account application 113 when the account number field 201receives focus (e.g., is selected by the user). The notification 204instructs the user to tap the contactless card 101 to the mobile device110. In one embodiment, the user selects the notification 204 prior totapping the contactless card 101 to the mobile device 110.

As stated, once the contactless card 101 is tapped to the mobile device110, the account application 113 transmits, via the card reader 118(e.g., via NFC, Bluetooth, RFID, and/or the EMV protocol etc.), anindication to the contactless card 101. The indication may specify togenerate a URL with encrypted data. As stated, the applet 103 maygenerate the URL with encrypted data using the private key 104 of thecontactless card. The applet 103 may then generate the URL withencrypted data as a parameter of the URL and transmit the URL withencrypted data to the mobile device 110. Once received, the URL withencrypted data may cause a page of the account application 113 to beopened.

FIG. 2B is a schematic 210 depicting an embodiment where the accountapplication 113 has been opened responsive to receiving the URL withencrypted data from the contactless card 101. As shown, the accountapplication 113 requires a user to provide a fingerprint to log in totheir account. In other embodiments, the user may log into the accountusing FaceID, other biometric identifiers, a username/password, or anyother type of credential. In some embodiments, user login is notrequired. Once the user logs in to the account, the account application113 transmits the encrypted data to the authentication application 123.Once verified (e.g., decrypted), the authentication application 123causes the VAN generator 142 to generate a virtual account number,expiration date, and CVV associated with the contactless card 101. TheVAN generator 142 may then transmit the virtual account number,expiration date, and CVV to the mobile device 110. As shown, oncereceived, the account application 113 copies the virtual account numberto the clipboard 114 of the OS. In one embodiment, the accountapplication 113 copies the virtual account number to the clipboard 114based on a determination that the account number field has focus. Theaccount application 113 may then generate and output a link 205 (orother graphical object) that allows the user to return to the previousapplication (e.g., the web browser 115).

FIG. 2C is a schematic 220 depicting an embodiment where the user hasselected the link 205 to return to the web browser 115. As shown, anotification 206 may allow the user to paste the virtual account numberto the form field 201 (e.g., after the user long presses on the formfield 201). Once selected, the OS 112 may cause the virtual card numberto be pasted from the clipboard 114 to the form field 201. FIG. 2D is aschematic 230 depicting an embodiment where the virtual account numberhas been pasted to the form field 201. As shown, the OS 112 and/or theaccount application 113 may output a notification 207. The notification207 includes the expiration date and CVV associated with the virtualaccount number that was received from the VAN generator 142. As shown,the notification 207 includes a link 208 which, when selected, copiesthe expiration date to the clipboard 114. Similarly, the notification207 includes a link 209 which, when selected, copies the CVV to theclipboard 114. Other graphical objects may be used instead of links. Insome embodiments, the outputting of the notification 207 is timed tofacilitate easy copy/pasting of the expiration date and CVV. Forexample, the account application 113 may start a timer responsive toreceiving the virtual account number, expiration date, and CVV from theVAN generator 142. As another example, the account application 113 maystart the timer when the user selects the link 205 to return to the webbrowser 115. Once the timer exceeds a predefined time threshold (e.g., 5seconds, 10 seconds, etc.), the notification 207 is generated andoutputted. Doing so gives the user time to paste the account number tothe form field 201 without being distracted by the notification 207,while providing the notification 207 in a timely manner to facilitatecopying and/or pasting of the expiration date and/or CVV.

FIG. 3A is a schematic 300 depicting an example embodiment of tappingthe contactless card 101 to generate a virtual account number and copythe virtual account number to the clipboard 114. As shown, the webbrowser 115 has loaded a website from a URL 305. The website includes aform having form fields 301-303 (e.g. a payment form) and may be in afirst tab of the web browser 115. The field 301 corresponds to anaccount number field, field 302 corresponds to an expiration date field,and field 303 corresponds to a CVV field. As shown, a notification 304is outputted by the OS 112 and/or the account application 113 when theaccount number field 301 receives focus (e.g., is selected by the user).The notification 304 instructs the user to tap the contactless card 101to the mobile device 110. In one embodiment, the user selects thenotification 304 prior to tapping the contactless card 101 to the mobiledevice 110.

To determine that a field has received focus, the account application113 and/or the OS 112 may analyze a hypertext markup language (HTML)attribute of the account number field 301 to determine that the accountnumber field 301 has received focus. Furthermore, the accountapplication 113 and/or the OS 112 may analyze the metadata of theaccount number field 301 to determine that the field 301 is associatedwith the account number. For example, the account application 113 and/orthe OS 112 may determine, based on the metadata, that the account numberfield 301 is configured to receive 16 characters as input. As anotherexample, the metadata may specify a name for the form field 301 that issimilar to names associated with account number fields (e.g.,“accountnumber”, “account number”, etc.).

As stated, once the contactless card 101 is tapped to the mobile device110, the account application 113 transmits, via the card reader 118(e.g., via NFC, Bluetooth, RFID, and/or the EMV protocol etc.), anindication to the contactless card 101. The indication may specify togenerate a URL with encrypted data. However, in some embodiments, thecontactless card 101 causes the applet 103 to generate the URL withencrypted data without requiring instructions received from the mobiledevice 110. As stated, the applet 103 may generate the URL withencrypted data using the private key 104 of the contactless card 101. Inthe example depicted in FIG. 3A, the applet 103 may generate the exampleencrypted string of “ABCD123XYZ” using the private key 104. The applet103 may then generate a URL to the authentication application 123, wherethe URL includes the encrypted data as a parameter of the URL. In theexample depicted in FIG. 3A, the URL with encrypted data may be“https:///www.example.com/auth.html?ABCD123XYZ”. The applet 103 may thentransmit the URL with encrypted data to the mobile device 110.

FIG. 3B is a schematic 310 illustrating an embodiment where a new tab ofthe web browser 115 is opened responsive to receiving the URL withencrypted data from the contactless card 101. As shown, the URL 306 ofthe web browser is directed to the URL with encrypted data generated bythe applet 103, namely “https:///www.example.com/auth.html?ABCD123XYZ”.The authentication application 123 may decrypt the encrypted data usingthe private key 104 to verify the encrypted data. The authenticationapplication 123 may then instruct the VAN generator 142 to generate avirtual account number, expiration date, and CVV. In some embodiments,however, the VAN generator 142 generates the virtual account number andselects an existing expiration date and/or CVV (e.g., from the accountdata 124). In some such examples, the existing expiration date and/orCVV may be the expiration date and/or CVV of the contactless card 101,or another card associated with the account in the account data 124.

As shown in FIG. 3B, the tab of the web browser 115 includes the virtualaccount number, expiration date, and CVV. In one embodiment, the VANgenerator 142 provides the generated data to the authenticationapplication 123. Doing so allows the authentication application 123 tooutput the data in the web browser 115. Other techniques may be used toredirect the web browser 115 to the VAN generator 142, which may outputthe virtual account number, expiration date, and CVV in the web browser115. As shown, the web browser 115 includes a notification to the userto close the tab of the web browser 115 once the user copies/pastes thevirtual account number, expiration date, and CVV.

FIG. 3C is a schematic 320 depicting an embodiment where the VANgenerator 142 and/or the authentication application 123 transmits a pushnotification 307 to the mobile device including the virtual accountnumber, expiration date, and CVV generated by the VAN generator 142. Thevirtual account number, expiration date, and CVV may be generated basedon any technique described herein. In one embodiment, the notification307 is generated instead of (or in addition to) outputting the virtualaccount number, expiration date, and CVV in the web browser 115 in FIG.3B. As shown, the notification 307 includes the virtual account number,expiration date, and CVV. As shown, the notification 307 includes a link308 which, when selected, copies the virtual account number to theclipboard 114. Similarly, the notification 307 includes a link 309which, when selected, copies the expiration date to the clipboard 114.Similarly, the notification 307 includes a link 321 which, whenselected, copies the CVV to the clipboard 114. Other graphical objectsmay be used instead of links. In some embodiments, the outputting of thenotification 307 is timed to facilitate easy copy/pasting of theexpiration date and CVV, e.g., upon expiration of a timer as describedabove.

FIG. 3D is a schematic 330 depicting an embodiment where the VANgenerator 142 and/or the authentication application 123 transmits a textmessage notification 311 to the mobile device including the virtualaccount number, expiration date, and CVV generated by the VAN generator142. The virtual account number, expiration date, and CVV may begenerated based on any technique described herein. In one embodiment,the text message notification 311 is generated instead of (or inaddition to) outputting the virtual account number, expiration date, andCVV in the web browser 115 in FIG. 3B. As shown, the text messagenotification 311 includes the virtual account number, expiration date,and CVV. As shown, the text message notification 311 includes a link 313which, when selected, copies the virtual account number to the clipboard114. Similarly, the text message notification 311 includes a link 314which, when selected, copies the expiration date to the clipboard 114.Similarly, the text message notification 311 includes a link 315 which,when selected, copies the CVV to the clipboard 114. Other graphicalobjects may be used instead of links. Furthermore, as shown, the textmessage 311 includes an autofill link 312, which when selected,autofills the virtual account number, expiration date, and CVV into theform fields 301-303, respectively. In at least one embodiment, anautofill service (not pictured) of the OS autofills the account number,expiration date, and CVV into the form fields 301-303. In someembodiments, the autofill service detects a form field (e.g., the formfields 301-303), detects content in a notification (e.g., thenotification 311) that has a type which matches the type of the detectedform field, and offers the content parsed from the notification into anautofill suggestion in the keyboard. Doing so allows the autofillservice to automatically fill the data from the notification to thecorresponding form fields.

Although not depicted in FIGS. 2A-2D and 3A-3D, the account holder name,billing address, and/or shipping address may be copied to the clipboard114 and pasted to corresponding form fields in the web browser. Asstated, the name, billing address, and/or shipping address may be storedlocally on the mobile device 110 and/or received from the VAN generator142 and/or the authentication server 120.

FIG. 4 illustrates an embodiment of a logic flow 400. The logic flow 400may be representative of some or all of the operations executed by oneor more embodiments described herein. For example, the logic flow 400may include some or all of the operations to use a contactless card togenerate a virtual account number and copy the virtual account number tothe clipboard 114. Embodiments are not limited in this context.

As shown, the logic flow 400 begins at block 405, where the accountapplication 113 and/or the OS 112 determines that a payment field of aform has received focus. The form may be in the web browser 115, theaccount application 113, and/or a different application. For example, auser may tap the payment field of the form to give the payment fieldfocus. As another example, the user may select the payment field of theform using a mouse and/or keyboard. More generally, any technique may beused to give the payment field focus, including programmaticallygenerated focus. For example, the payment field may receive focus basedon the HTML “focus( )” method. As another example, the payment field mayautomatically receive focus when the form is loaded, e.g., based on the“autofocus” HTML attribute being applied to the payment field in sourcecode. The payment field may include one or more of a name field, anaccount number field, expiration date field, a shipping address field, abilling address field, and/or a CVV field. Once the payment fieldreceives focus, the account application 113 and/or the OS 112 may outputa notification specifying to the user to tap the contactless card 101 tothe mobile device 110. In some embodiments, the notification may begenerated based on a determination that the form includes one or morepayment fields and without requiring a determination that the form fieldhas received focus. The notification may include a GUI which provides anexample of how to tap the contactless card 101 to the mobile device 110.At block 410, a user taps the contactless card 101 to the mobile deviceto cause the contactless card 101 to generate and transmit encrypteddata as part of a URL. The account application 113 may transmit anindication to the contactless card 101 via the NFC card reader 118specifying to generate and transmit encrypted data as part of the URL.

At block 415, the applet 103 of the contactless card generates theencrypted data using the private key 104 and a cryptographic algorithm.The applet 103 may then include the encrypted data as a parameter of aURL. The URL may be a universal link URL which at least in part causes apredefined page of the account application 113 to be opened whenfollowed. At block 420, the applet 103 may transmit the URL includingthe encrypted data to the mobile device 110. At block 425, the accountapplication 113 is opened to the page corresponding to the universallink URL received from the contactless card 101. In some embodiments,the account application 113 may require the user to log in to theiraccount (if not already logged in). In some such embodiments, the URLmay be directed to an external authentication website configured toreceive credentials required to log the user in to their account. Asanother example, the URL may be directed to an authentication page ofthe account application 113 that receives credentials required to logthe user in to their account.

At block 430, the account application 113 extracts the encrypted datafrom the URL and transmits the encrypted data to the authenticationapplication 123 of the authentication server 120 for verification. Ifthe encrypted data is encoded, the account application 113 and/or theauthentication application 123 may decode the encrypted data. At block435, the authentication application 123 decrypts the encrypted datausing the private key in the memory of the server 120 to validate theencrypted data. At block 440, the authentication application 123transmits an indication to the VAN generator 142 specifying to generatea virtual account number, expiration date, and CVV. The authenticationapplication 123 may further specify one or more restrictions on thevirtual account number (e.g., must be used within 1 hour, can only beused at a specified merchant's website, etc.). At block 445, the VANgenerator 142 generates the virtual account number, expiration date, andCVV. At block 450, the VAN generator 142 transmits the virtual accountnumber, expiration date, and CVV to the mobile device 110. The VANgenerator 142 may further transmit the account holder name, billingaddress, and/or shipping address to the mobile device 110, which may bereceived by the VAN generator 142 from the authentication server 120.For example, the VAN generator 142 may generate a push notification, atext message, or one or more data packets processed by the accountapplication 113 to receive the virtual account number, expiration date,and CVV.

At block 455, the account application 113 copies the virtual accountnumber to the clipboard 114 of the OS. The account application 113 mayfurther start a timer. At block 460, the user may return to the webbrowser 115, and paste the virtual account number stored in theclipboard 114 to the payment field of the form. At block 465, theaccount application 113 outputs a notification specifying the accountholder name, billing address, shipping address, expiration date, and/orCVV after the timer set at block 455 elapses (or exceeds a thresholdamount of time). Doing so allows the user to copy and paste the accountholder name, billing address, shipping address, expiration date, and/orCVV to the corresponding fields of the form.

FIG. 5 illustrates an embodiment of a logic flow 500. The logic flow 500may be representative of some or all of the operations executed by oneor more embodiments described herein. For example, the logic flow 500may include some or all of the operations to use a contactless card togenerate a virtual account number and copy the virtual account number tothe clipboard 114. Embodiments are not limited in this context.

As shown, the logic flow 500 begins at block 505, where the accountapplication 113 and/or the OS 112 determines that a payment field of aform has received focus. The form may be in the web browser 115, theaccount application 113, and/or a different application. For example, auser may tap the payment field of the form to give the payment fieldfocus. As another example, the user may select the payment field of theform using a mouse and/or keyboard. More generally, any technique may beused to give the payment field focus, including programmaticallygenerated focus. For example, the payment field may receive focus basedon the HTML “focus( )” method. As another example, the payment field mayautomatically receive focus when the form is loaded, e.g., based on the“autofocus” HTML attribute being applied to the payment field in sourcecode. The payment field may include one or more of a name field, anaccount number field, expiration date field, a shipping address field, abilling address field, and/or a CVV field. Once the payment fieldreceives focus, the account application 113 and/or the OS 112 may outputa notification specifying to the user to tap the contactless card 101 tothe mobile device 110. In some embodiments, the notification may begenerated based on a determination that the form includes one or morepayment fields. The notification may include a GUI which depicts anexample of how to tap the contactless card 101 to the mobile device 110.At block 510, a user taps the contactless card 101 to the mobile deviceto cause the contactless card 101 to generate and transmit data as partof a URL. The account application 113 may transmit an indication to thecontactless card 101 via the NFC card reader 118 specifying to generateand transmit data as part of the URL.

At block 515, the applet 103 of the contactless card generates a URLwhich include an account identifier (or a portion thereof) as aparameter of the URL. The URL may be a universal link URL which at leastin part causes a predefined page of the account application 113 to beopened when followed. At block 520, the applet 103 may transmit the URLincluding the account identifier to the mobile device 110. At block 525,the account application 113 is opened to the page corresponding to theuniversal link URL received from the contactless card 101. In someembodiments, the account application 113 may require the user to log into their account (if not already logged in).

At block 530, the account application 113 extracts the accountidentifier from the URL and transmits the account identifier to theauthentication application 123 of the authentication server 120 forverification. At block 535, the authentication application 123 validatesthe account identifier (e.g., by determining whether the receivedaccount identifier matches an expected and/or known account identifiervalue). At block 540, the authentication application 123 transmits anindication to the VAN generator 142 specifying to generate a virtualaccount number, expiration date, and CVV. The authentication application123 may further specify one or more restrictions on the virtual accountnumber (e.g., must be used within 1 hour, can only be used at aspecified merchant's website, etc.). At block 545, the VAN generator 142generates the virtual account number, expiration date, and CVV. At block550, the VAN generator 142 transmits the virtual account number,expiration date, and CVV to the mobile device 110. The VAN generator 142may further transmit the account holder name, billing address, and/orshipping address to the mobile device 110, which may be received by theVAN generator 142 from the authentication server 120. For example, theVAN generator 142 may generate a push notification, a text message, orone or more data packets processed by the account application 113 toreceive the virtual account number, expiration date, and CVV.

At block 555, the account application 113 copies the virtual accountnumber to the clipboard 114 of the OS. The account application 113 mayfurther start a timer. At block 560, the user may return to the webbrowser 115, and paste the virtual account number stored in theclipboard 114 to the payment field of the form. At block 565, theaccount application 113 outputs a notification specifying the accountholder name, billing address, shipping address, expiration date, and/orCVV after the timer set at block 555 elapses (or exceeds a thresholdamount of time). Doing so allows the user to copy and paste the accountholder name, billing address, shipping address, expiration date, and/orCVV to the corresponding fields of the form.

FIG. 6 illustrates an embodiment of a logic flow 600. The logic flow 600may be representative of some or all of the operations executed by oneor more embodiments described herein. For example, the logic flow 600may include some or all of the operations to use a contactless card togenerate a virtual account number and copy the virtual account number tothe clipboard 114. Embodiments are not limited in this context.

As shown, the logic flow 600 begins at block 605, where the accountapplication 113 and/or the OS 112 determines that a payment field of aform has received focus. The form may be in a first tab of the webbrowser 115. For example, a user may tap the payment field of the formto give the payment field focus. As another example, the user may selectthe payment field of the form using a mouse and/or keyboard. Moregenerally, any technique may be used to give the payment field focus,including programmatically generated focus. For example, the paymentfield may receive focus based on the HTML “focus( )” method. As anotherexample, the payment field may automatically receive focus when the formis loaded, e.g., based on the “autofocus” HTML attribute being appliedto the payment field in source code. The payment field may include oneor more of a name field, an account number field, expiration date field,a shipping address field, a billing address field, and/or a CVV field.Once the payment field receives focus, the account application 113and/or the OS 112 may output a notification specifying to the user totap the contactless card 101 to the mobile device 110. In someembodiments, the notification may be generated based on a determinationthat the form includes one or more payment fields. The notification mayinclude a GUI which depicts an example of how to tap the contactlesscard 101 to the mobile device 110. At block 610, a user taps thecontactless card 101 to the mobile device to cause the contactless card101 to generate and transmit encrypted data as part of a URL. Theaccount application 113 may transmit an indication to the contactlesscard 101 via the NFC card reader 118 specifying to generate and transmitencrypted data as part of the URL.

At block 615, the applet 103 of the contactless card generates theencrypted data using the private key 104 and a cryptographic algorithm.The applet 103 may then include the encrypted data as a parameter of aURL. The URL may be a URL to the authentication application 123 and/orthe authentication server 120 which causes a second tab of the webbrowser 115 to be opened. At block 620, the applet 103 may transmit theURL including the encrypted data to the mobile device 110. At block 625,the web browser 115 opens a second tab and loads the URL including theencrypted data.

At block 630, the authentication application 123 extracts the encrypteddata from the URL and decrypts the encrypted data using the private keyin the memory of the server 120 to validate the encrypted data. At block635, the authentication application 123 transmits an indication to theVAN generator 142 specifying to generate a virtual account number,expiration date, and CVV. The authentication application 123 may furtherspecify one or more restrictions on the virtual account number (e.g.,must be used within 1 hour, can only be used at a specified merchant'swebsite, etc.). At block 640, the VAN generator 142 generates thevirtual account number, expiration date, and CVV.

At block 645, the VAN generator 142 transmits a push notificationcomprising the virtual account number, expiration date, and CVV to themobile device 110. The VAN generator 142 may further transmit theaccount holder name, billing address, and/or shipping address as part ofthe push notification. The mobile device 110 may then output thereceived push notification. In addition and/or alternatively, at block650, the VAN generator 142 transmits a text message comprising thevirtual account number, expiration date, and CVV to the mobile device110. The mobile device 110 may then output a notification correspondingto the text message, where the notification displays the virtual accountnumber, expiration date, and CVV. In addition and/or alternatively, atblock 655, the virtual account number, expiration date, CVV, accountholder name, billing address, and/or shipping address are optionallyoutputted for display in the second tab of the web browser 115. At block660, one or more of the virtual account number, expiration date, CVV,account holder name, billing address, and/or shipping address may becopied from one or more of the push notification, the text messagenotification, and the second browser tab, and pasted into the form inthe first browser tab. In addition and/or alternatively, the virtualaccount number, expiration date, CVV, account holder name, billingaddress, and/or shipping address may be autofilled into the form.

FIG. 7 illustrates an embodiment of an exemplary computing architecture700 comprising a computing system 702 that may be suitable forimplementing various embodiments as previously described. In variousembodiments, the computing architecture 700 may comprise or beimplemented as part of an electronic device. In some embodiments, thecomputing architecture 700 may be representative, for example, of asystem that implements one or more components of the system 100. In someembodiments, computing system 702 may be representative, for example, ofthe mobile devices 110, authentication server 120, and/or the virtualaccount number server 140 of the system 100. The embodiments are notlimited in this context. More generally, the computing architecture 700is configured to implement all logic, applications, systems, methods,apparatuses, and functionality described herein with reference to FIGS.1-6 .

As used in this application, the terms “system” and “component” and“module” are intended to refer to a computer-related entity, eitherhardware, a combination of hardware and software, software, or softwarein execution, examples of which are provided by the exemplary computingarchitecture 700. For example, a component can be, but is not limited tobeing, a process running on a computer processor, a computer processor,a hard disk drive, multiple storage drives (of optical and/or magneticstorage medium), an object, an executable, a thread of execution, aprogram, and/or a computer. By way of illustration, both an applicationrunning on a server and the server can be a component. One or morecomponents can reside within a process and/or thread of execution, and acomponent can be localized on one computer and/or distributed betweentwo or more computers. Further, components may be communicativelycoupled to each other by various types of communications media tocoordinate operations. The coordination may involve the uni-directionalor bi-directional exchange of information. For instance, the componentsmay communicate information in the form of signals communicated over thecommunications media. The information can be implemented as signalsallocated to various signal lines. In such allocations, each message isa signal. Further embodiments, however, may alternatively employ datamessages. Such data messages may be sent across various connections.Exemplary connections include parallel interfaces, serial interfaces,and bus interfaces.

The computing system 702 includes various common computing elements,such as one or more processors, multi-core processors, co-processors,memory units, chipsets, controllers, peripherals, interfaces,oscillators, timing devices, video cards, audio cards, multimediainput/output (I/O) components, power supplies, and so forth. Theembodiments, however, are not limited to implementation by the computingsystem 702.

As shown in FIG. 7 , the computing system 702 comprises a processor 704,a system memory 706 and a system bus 708. The processor 704 can be anyof various commercially available computer processors, including withoutlimitation an AMD® Athlon®, Duron® and Opteron® processors; ARM®application, embedded and secure processors; IBM® and Motorola®DragonBall® and PowerPC® processors; IBM and Sony® Cell processors;Intel® Celeron®, Core®, Core (2) Duo®, Itanium®, Pentium®, Xeon®, andXScale® processors; and similar processors. Dual microprocessors,multi-core processors, and other multi processor architectures may alsobe employed as the processor 704.

The system bus 708 provides an interface for system componentsincluding, but not limited to, the system memory 706 to the processor704. The system bus 708 can be any of several types of bus structurethat may further interconnect to a memory bus (with or without a memorycontroller), a peripheral bus, and a local bus using any of a variety ofcommercially available bus architectures. Interface adapters may connectto the system bus 708 via a slot architecture. Example slotarchitectures may include without limitation Accelerated Graphics Port(AGP), Card Bus, (Extended) Industry Standard Architecture ((E)ISA),Micro Channel Architecture (MCA), NuBus, Peripheral ComponentInterconnect (Extended) (PCI(X)), PCI Express, Personal Computer MemoryCard International Association (PCMCIA), and the like.

The system memory 706 may include various types of computer-readablestorage media in the form of one or more higher speed memory units, suchas read-only memory (ROM), random-access memory (RAM), dynamic RAM(DRAM), Double-Data-Rate DRAM (DDRAM), synchronous DRAM (SDRAM), staticRAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM),electrically erasable programmable ROM (EEPROM), flash memory (e.g., oneor more flash arrays), polymer memory such as ferroelectric polymermemory, ovonic memory, phase change or ferroelectric memory,silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or opticalcards, an array of devices such as Redundant Array of Independent Disks(RAID) drives, solid state memory devices (e.g., USB memory, solid statedrives (SSD) and any other type of storage media suitable for storinginformation. In the illustrated embodiment shown in FIG. 7 , the systemmemory 706 can include non-volatile memory 710 and/or volatile memory712. A basic input/output system (BIOS) can be stored in thenon-volatile memory 710.

The computing system 702 may include various types of computer-readablestorage media in the form of one or more lower speed memory units,including an internal (or external) hard disk drive (HDD) 714, amagnetic floppy disk drive (FDD) 716 to read from or write to aremovable magnetic disk 718, and an optical disk drive 720 to read fromor write to a removable optical disk 722 (e.g., a CD-ROM or DVD). TheHDD 714, FDD 716 and optical disk drive 720 can be connected to thesystem bus 708 by a HDD interface 724, an FDD interface 726 and anoptical drive interface 728, respectively. The HDD interface 724 forexternal drive implementations can include at least one or both ofUniversal Serial Bus (USB) and IEEE 1394 interface technologies. Thecomputing system 702 is generally is configured to implement all logic,systems, methods, apparatuses, and functionality described herein withreference to FIGS. 1-6 .

The drives and associated computer-readable media provide volatileand/or nonvolatile storage of data, data structures, computer-executableinstructions, and so forth. For example, a number of program modules canbe stored in the drives and memory units 710, 712, including anoperating system 730, one or more application programs 732, otherprogram modules 734, and program data 736. In one embodiment, the one ormore application programs 732, other program modules 734, and programdata 736 can include, for example, the various applications and/orcomponents of the system 100, e.g., the operating system 112, accountapplication 113, clipboard 114, web browser 115, the authenticationapplication 123, and the VAN generator 142.

A user can enter commands and information into the computing system 702through one or more wire/wireless input devices, for example, a keyboard738 and a pointing device, such as a mouse 740. Other input devices mayinclude microphones, infra-red (IR) remote controls, radio-frequency(RF) remote controls, game pads, stylus pens, card readers, dongles,finger print readers, gloves, graphics tablets, joysticks, keyboards,retina readers, touch screens (e.g., capacitive, resistive, etc.),trackballs, trackpads, sensors, styluses, and the like. These and otherinput devices are often connected to the processor 704 through an inputdevice interface 742 that is coupled to the system bus 708, but can beconnected by other interfaces such as a parallel port, IEEE 1394 serialport, a game port, a USB port, an IR interface, and so forth.

A monitor 744 or other type of display device is also connected to thesystem bus 708 via an interface, such as a video adaptor 746. Themonitor 744 may be internal or external to the computing system 702. Inaddition to the monitor 744, a computer typically includes otherperipheral output devices, such as speakers, printers, and so forth.

The computing system 702 may operate in a networked environment usinglogical connections via wire and/or wireless communications to one ormore remote computers, such as a remote computer 748. The remotecomputer 748 can be a workstation, a server computer, a router, apersonal computer, portable computer, microprocessor-based entertainmentappliance, a peer device or other common network node, and typicallyincludes many or all of the elements described relative to the computingsystem 702, although, for purposes of brevity, only a memory/storagedevice 750 is illustrated. The logical connections depicted includewire/wireless connectivity to a local area network (LAN) 752 and/orlarger networks, for example, a wide area network (WAN) 754. Such LANand WAN networking environments are commonplace in offices andcompanies, and facilitate enterprise-wide computer networks, such asintranets, all of which may connect to a global communications network,for example, the Internet. In embodiments, the network 130 of FIG. 1 isone or more of the LAN 752 and the WAN 754.

When used in a LAN networking environment, the computing system 702 isconnected to the LAN 752 through a wire and/or wireless communicationnetwork interface or adaptor 756. The adaptor 756 can facilitate wireand/or wireless communications to the LAN 752, which may also include awireless access point disposed thereon for communicating with thewireless functionality of the adaptor 756.

When used in a WAN networking environment, the computing system 702 caninclude a modem 758, or is connected to a communications server on theWAN 754, or has other means for establishing communications over the WAN754, such as by way of the Internet. The modem 758, which can beinternal or external and a wire and/or wireless device, connects to thesystem bus 708 via the input device interface 742. In a networkedenvironment, program modules depicted relative to the computing system702, or portions thereof, can be stored in the remote memory/storagedevice 750. It will be appreciated that the network connections shownare exemplary and other means of establishing a communications linkbetween the computers can be used.

The computing system 702 is operable to communicate with wired andwireless devices or entities using the IEEE 802 family of standards,such as wireless devices operatively disposed in wireless communication(e.g., IEEE 802.16 over-the-air modulation techniques). This includes atleast Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth™ wirelesstechnologies, among others. Thus, the communication can be a predefinedstructure as with a conventional network or simply an ad hoccommunication between at least two devices. Wi-Fi networks use radiotechnologies called IEEE 802.11x (a, b, g, n, etc.) to provide secure,reliable, fast wireless connectivity. A Wi-Fi network can be used toconnect computers to each other, to the Internet, and to wire networks(which use IEEE 802.3-related media and functions).

Various embodiments may be implemented using hardware elements, softwareelements, or a combination of both. Examples of hardware elements mayinclude processors, microprocessors, circuits, circuit elements (e.g.,transistors, resistors, capacitors, inductors, and so forth), integratedcircuits, application specific integrated circuits (ASIC), programmablelogic devices (PLD), digital signal processors (DSP), field programmablegate array (FPGA), logic gates, registers, semiconductor device, chips,microchips, chip sets, and so forth. Examples of software may includesoftware components, programs, applications, computer programs,application programs, system programs, machine programs, operatingsystem software, middleware, firmware, software modules, routines,subroutines, functions, methods, procedures, software interfaces,application program interfaces (API), instruction sets, computing code,computer code, code segments, computer code segments, words, values,symbols, or any combination thereof. Determining whether an embodimentis implemented using hardware elements and/or software elements may varyin accordance with any number of factors, such as desired computationalrate, power levels, heat tolerances, processing cycle budget, input datarates, output data rates, memory resources, data bus speeds and otherdesign or performance constraints.

One or more aspects of at least one embodiment may be implemented byrepresentative instructions stored on a machine-readable medium whichrepresents various logic within the processor, which when read by amachine causes the machine to fabricate logic to perform the techniquesdescribed herein. Such representations, known as “IP cores” may bestored on a tangible, machine readable medium and supplied to variouscustomers or manufacturing facilities to load into the fabricationmachines that make the logic or processor. Some embodiments may beimplemented, for example, using a machine-readable medium or articlewhich may store an instruction or a set of instructions that, ifexecuted by a machine, may cause the machine to perform a method and/oroperations in accordance with the embodiments. Such a machine mayinclude, for example, any suitable processing platform, computingplatform, computing device, processing device, computing system,processing system, computer, processor, or the like, and may beimplemented using any suitable combination of hardware and/or software.The machine-readable medium or article may include, for example, anysuitable type of memory unit, memory device, memory article, memorymedium, storage device, storage article, storage medium and/or storageunit, for example, memory, removable or non-removable media, erasable ornon-erasable media, writeable or re-writeable media, digital or analogmedia, hard disk, floppy disk, Compact Disk Read Only Memory (CD-ROM),Compact Disk Recordable (CD-R), Compact Disk Rewriteable (CD-RW),optical disk, magnetic media, magneto-optical media, removable memorycards or disks, various types of Digital Versatile Disk (DVD), a tape, acassette, or the like. The instructions may include any suitable type ofcode, such as source code, compiled code, interpreted code, executablecode, static code, dynamic code, encrypted code, and the like,implemented using any suitable high-level, low-level, object-oriented,visual, compiled and/or interpreted programming language.

The foregoing description of example embodiments has been presented forthe purposes of illustration and description. It is not intended to beexhaustive or to limit the present disclosure to the precise formsdisclosed. Many modifications and variations are possible in light ofthis disclosure. It is intended that the scope of the present disclosurebe limited not by this detailed description, but rather by the claimsappended hereto. Future filed applications claiming priority to thisapplication may claim the disclosed subject matter in a differentmanner, and may generally include any set of one or more limitations asvariously disclosed or otherwise demonstrated herein.

What is claimed is:
 1. A method, comprising: receiving, by a processorof a device and from a card, a link and encrypted data; opening, by anoperating system (OS) executing on the processor, an application basedon the link; transmitting, by the application, the encrypted data to anauthentication server; receiving, by the application based on the serververifying the encrypted data, account data; and storing, by theapplication, the account data in a memory of the device.
 2. The methodof claim 1, wherein the link comprises a universal link URL directed toa page of the application.
 3. The method of claim 1, wherein storing theaccount data comprises providing the account data to a clipboard of theOS.
 4. The method of claim 3, further comprising: pasting, by the OS,the account data from the clipboard to a payment field of a form.
 5. Themethod of claim 1, wherein the account data comprises one or more of anaccount number, an expiration date of the account number, a cardverification value (CVV) of the account number, or a billing address,the method further comprising: copying, by the application, one of theaccount number, the expiration date, the CVV, or the billing address toa clipboard of the OS; and pasting, by the OS, the one of the accountnumber, the expiration date, the CVV, and the billing address from theclipboard to a field of a payment form.
 6. The method of claim 1,further comprising prior to opening the application: determining, by theprocessor, that the link comprises a page of an application; andopening, by the OS, the page of the application based on the link. 7.The method of claim 1, further comprising: receiving, by the OS, a pushnotification; and outputting, by the OS, the push notification fordisplay.
 8. The method of claim 1, wherein the link and the encrypteddata are received via near-field communications (NFC) and in an NFC DataExchange Format (NDEF).
 9. A non-transitory computer-readable storagemedium, the computer-readable storage medium including instructions thatwhen executed by a processor, cause the processor to: receive, from acard, a link and encrypted data; open, by an operating system (OS), anapplication based on the link; transmit, by the application, theencrypted data to an authentication server; receive, by the applicationbased on the server verifying the encrypted data, account data; andstore, by the application, the account data.
 10. The computer-readablestorage medium of claim 9, wherein the link comprises a universal linkURL directed to a page of the application.
 11. The computer-readablestorage medium of claim 9, wherein storing the account data comprisesproviding the account data to a clipboard of the OS.
 12. Thecomputer-readable storage medium of claim 11, wherein the instructionsfurther cause the processor to: paste, by the OS, the account data fromthe clipboard to a payment field of a form.
 13. The computer-readablestorage medium of claim 9, wherein the account data comprises one ormore of an account number, an expiration date of the account number, acard verification value (CVV) of the account number, or a billingaddress, wherein the instructions further cause the processor to: copy,by the application, one of the account number, the expiration date, theCVV, or the billing address to a clipboard of the OS; and paste, by theOS, the one of the account number, the expiration date, the CVV, and thebilling address from the clipboard to a field of a payment form.
 14. Thecomputer-readable storage medium of claim 9, wherein the instructionsfurther cause the processor to, prior to opening the application:determine that the link comprises a page of an application; and open, bythe OS, the page of the application based on the link.
 15. Thecomputer-readable storage medium of claim 9, wherein the link and theencrypted data are received via near-field communications (NFC) and inan NFC Data Exchange Format (NDEF).
 16. A computing apparatuscomprising: a wireless card reader; a processor; and a memory storinginstructions that, when executed by the processor, cause the processorto: receive, via the wireless card reader, a link and encrypted datafrom a card; open, by an operating system (OS), an application based onthe link; transmit, by the application, the encrypted data to anauthentication server; receive, by the application based on the serververifying the encrypted data, account data; and store, by theapplication, the account data in the memory.
 17. The computing apparatusof claim 16, wherein the link comprises a universal link URL directed toa page of the application.
 18. The computing apparatus of claim 16,wherein storing the account data comprises providing the account data toa clipboard of the OS.
 19. The computing apparatus of claim 18, whereinthe instructions further cause the processor to: paste, by the OS, theaccount data from the clipboard to a payment field of a form.
 20. Thecomputing apparatus of claim 16, wherein the account data comprises oneor more of an account number, an expiration date of the account number,a card verification value (CVV) of the account number, or a billingaddress, wherein the instructions further cause the processor to: copy,by the application, one of the account number, the expiration date, theCVV, or the billing address to a clipboard of the OS; and paste, by theOS, the one of the account number, the expiration date, the CVV, and thebilling address from the clipboard to a field of a payment form.